Exchange storage key DKG artifacts over Iroh - #2434
huitseeker wants to merge 28 commits into
Conversation
1e1d453 to
4550f53
Compare
|
I think broadly speaking this would benefit from an explanation/goal and having the code model that. |
3258fcb to
48e8586
Compare
huitseeker
changed the title
df7aa83 to
008bd45
Compare
5abd9b9 to
3a27882
Compare
3a27882 to
54e06b2
Compare
54e06b2 to
95fc9f5
Compare
|
I'll need to dig into the actual DKG ceremony in more detail first; I'd also like to know what alternatives there are to a central board, or how this would operate for a live network key rotation. I imagine we would want something like this to share txs for new incoming validators etc. This is beyond the purvey of this PR, but I need to just wrap my head around things. |
d2bd377 to
20579f5
Compare
20579f5 to
0ee1a12
Compare
|
|
||
| services: | ||
| # Opt-in end-to-end check for the Iroh exchange. Validator bootstrap is defined in node.yml. | ||
| storage-key-dkg-check: |
There was a problem hiding this comment.
This is manually reimplementing what compose already does — supervising processes, propagating failures, tearing down. Should we split this into services using the same anchor pattern the file already uses for x-validator:
x-dkg-runner: &dkg-runner
profiles: ["storage-key-dkg"]
image: ${MIDEN_VALIDATOR_IMAGE:-miden-validator}
volumes: [node-data:/data]
entrypoint: ["/bin/sh", "-c"]
command:
- |
until [ -s "/data/storage-key-dkg-check/board-tickets/participant-$${PARTICIPANT}.ticket" ]; do sleep 1; done
exec miden-validator dkg run --board-file ... --signing-key.hex "$${SIGNING_KEY}" ...
services:
storage-key-dkg-board: # runs `dkg board`
storage-key-dkg-runner-1: { <<: *dkg-runner, environment: { PARTICIPANT: 1, SIGNING_KEY: "0101…" } }
storage-key-dkg-runner-2: { <<: *dkg-runner, environment: { PARTICIPANT: 2, SIGNING_KEY: "0303…" } }
storage-key-dkg-runner-3: { <<: *dkg-runner, environment: { PARTICIPANT: 3, SIGNING_KEY: "0404…" } }
storage-key-dkg-check: # depends_on the 3 runners with service_completed_successfully;
# body shrinks to just the cmp assertionsThere was a problem hiding this comment.
Also we need to consider whether we should update run-node.sh to allow for a setup using dkg/iroh.
There was a problem hiding this comment.
The DKG process is actually synchronous and requires participants to be online and active — it's a hard limitation. The storage-key-dkg-check runs through docker compose run --rm. It must return one result and leave no helper services behind. Keeping the board and runners in that job does both.
run-node.sh starts long-running node services. Due to that synchronous limitation, I've left this alone: the DKG is a one-time ceremony and it's arguable whether it should run on each node start (e.g. it won't work for restarts, see above). If local setup needs one entry point, I'd add a run-dkg.sh command that finishes before run-node.sh starts the node, in a followup.
1960a55 to
dc1282b
Compare
Regenerate the lockfile against the refreshed dependency graph. This removes the stale duplicate lru entry while keeping the reviewed Iroh versions.
Read validator keys through the validator configuration stored in the genesis header. Remove the unused lockfile entry left by the rebase conflict.
dc1282b to
078ba31
Compare
3 participants
Stacked on #2433.
This replaces manual public file exchange with one shared Iroh document. One operator starts
dkg boardfrom the genesis file, threshold, and epoch, then sends the private ticket to each validator through the trusted bootstrap channel. Each operator runsdkg runwith that ticket, the genesis file, its signing key, a private work directory, and an output directory.The runners exchange signed public artifacts, resume after restarts, and write local storage key bundles. Operators compare the shared public output, keep each secret share private, and start validators only after every runner succeeds. An opt-in Compose check runs the full three-validator flow.
Changelog